Presently, the deployment of protection for sensitive data in a database is not a straight-forward task, which makes adhering to security compliance requirements difficult. For example, it is difficult to easily convert data security standards or requirements, like the ones that are set by the Payment Card Industry Data Security Standard (PCI-DSS), the Health Insurance Portability and Accountability Act (HIPAA), or even organization-specific guidelines, into security policies that achieve the same. This is because security standards encompass or prescribe many different data security technologies for sensitive data. For example, a security requirement can be that Social Security Numbers (SSN) need AES-128 encryption, need to be accessed only by some privileged Database Users (or applications), and all SELECTS on the data need to be audited. Thus, in this example, encryption, access control, and auditing are three different security technologies that are prescribed for SSNs. Today, applying these three security technologies to SSNs can be achieved with a two-phase task, Phase 1 being a pre-requisite for Phase 2.
Phase 1 is the identification of sensitive data in a database. All the columns that contain SSNs (i.e., the sensitive data in this example) need to be identified. For this, one needs to know that Social Security Numbers have 9 digits and the exact schemas, tables, and columns storing that data. In a real-world scenario where an organization might have sensitive data stored across many schemas, identifying each of the individual columns is non-trivial. This issue gets multiplied by the number of databases that the organization has.
Phase 2 involves enforcing protection on the identified sensitive data. Each of the prescribed security technologies has to be enforced individually on each of the identified sensitive data. Given the example above, encryption, access control, and auditing have to be individually deployed on each of the columns that are identified as containing Social Security Numbers, and this can be done today by having three different security policies for each of the three individual security requirements of the same compliance policy. Today, each security technology that is to be enforced requires its own separate policy.
Another problem with this approach is that in the real-world protection requirements keep changing. Highly distributed work environments add to this problem and require that security policies change with time and keep up with the changing requirements. This makes adapting to changing compliance requirements difficult.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.